feat(sparql-anything): convert several chunks at once - #795

map.sh runs an xargs -P pool over its chunks; the converter ran them one at a
time, which on allCountries multiplies a job that already takes about a day.
concurrency says how many to convert at once, over the chunks of every job in
one pool, so a long places chunk and a short alternate-names one pack together
rather than draining in phases.

The output is concatenated by position, not by completion, so it stays in the
order the jobs and their chunks were given. The first failure aborts the run:
no further chunk is started, and the processes still going are stopped rather
than left writing into a directory convert() is about to delete.

The default is 1, and deliberately not derived from the CPU count or a memory
limit. Each chunk is a JVM capped by `heap`, so a pool needs concurrency × heap
on the machine the TASK RUNNER uses – which is not this process's machine once
the runner is Docker or remote. The converter cannot see that machine, so the
number belongs to the caller, who can do map.sh's arithmetic for the
deployment they actually have.

Workers pull from the queue one at a time rather than sharing a for...of over
it: leaving a for-of early closes the iterator, so the first worker to give up
would silently end the queue for the others.

…e failure

Three ways the abort could go wrong, all of them found by review:

- Stopping was unguarded. A task runner cannot stop what has already exited –
  DockerTaskRunner's stop() reads logs and stops the container, and both reject
  for one that is gone – so a stop failure replaced the conversion failure and
  rejected the join, leaving the other workers unawaited while the run
  directory was deleted underneath them. Stopping is best effort now.
- A chunk could be started after the run had failed. The guard sits before two
  awaits, so a worker could pass it, then start a process while another chunk
  was failing; that process was not in the set the failure stopped, and the
  run waited out its whole conversion. Each worker now checks once its process
  exists, and stops it.
- A DockerTaskRunner with a containerName force-removes any container of that
  name before starting a task, so chunks in parallel would destroy each
  other's containers. Documented as a warning; the runner needs a per-task
  name before that combination can work.

The fake task runner's delays never applied: they were keyed by file name
while the command names the output relative to the run directory, so every
lookup missed and every delay was zero. Two tests that read as though they
staged an ordering were passing on whatever order the event loop produced.